March 97 - Macintosh Q & A
Macintosh Q & A
Q I noticed in QuickTime 2.5 that there are new selectors in the Movie Import API that aren't described in Inside Macintosh: QuickTime Components. Although I found
some information in Technote QT 04, "QuickTime 1.6.1 Features," I haven't been able
to locate any information about the kMovieImportGetFileTypeSelect and
kMovieImportDataRefSelect selectors. Can you tell me something about these?
A The kMovieImportGetFileTypeSelect and kMovieImportDataRefSelect selectors were added to support some features that were under investigation with the QuickTime
for Netscape plug-in. While these selectors are supported by some of the Apple movie
data import components, they don't provide any new functionality and there's no reason
to consider implementing them in your movie data import component at this time.
Q My application plays four QuickTime movies simultaneously from a Director project. Each of the movies has a single music track with no other video or sound
tracks, and two of the movies use more than one instrument. The Director project
allows the user to control the volume level of each movie independently. The
application works great on the Macintosh with QuickTime 2.1, but under Windows
with QuickTime 2.1.2 only one music track plays at a time. Is it possible to hear all
four music tracks at once under QuickTime for Windows 2.1.2?
A You can do live mixing of your four QuickTime movies only if your Windows system has four MIDI output devices. Most systems have only one. All Windows
applications suffer from this limitation unless they're clever enough to mix the tracks
on the fly, but none seem to do this.
For now, you must pre-mix the four music tracks from the four movies into one
music track in one movie. You won't be able to do live mixing unless you write your
own MIDI sequencer.
Q Can I play a compressed WAVE file on the Macintosh? A Yes. You can use the Sound Manager to play a compressed WAVE file on the Macintosh, but how easy it will be can vary greatly, depending on the type of
compression.
If the WAVE file is compressed using ulaw, your program will have to use either
SndPlayDoubleBuffer or SndDoCommand with bufferCmds to play the sound
(QuickTime cannot currently be used). This means that you'll have to parse the WAVE
header yourself and interact with the Sound Manager at a lower level than is possible
by simply calling SndStartFilePlay.
Currently, you can't play an IMA-ADPCM compressed WAVE file as easily as a 'ulaw'
compressed WAVE file, because the data stream of a sound compressed with Windows'
IMA-ADPCM compressor differs from the data stream of the same sound compressed
with the Macintosh's IMA compressor. To play an IMA-ADPCM compressed WAVE file
on the Macintosh, your application will first have to decompress chunks of the sound
into memory, then have the Sound Manager play those chunks. You can do this either by
calling SndPlayDoubleBuffer or by using bufferCmds. Of course, if the uncompressed
sound fits completely into memory, you can simply use SndPlay on that one
uncompressed buffer.
To play a WAVE file that uses a custom compression algorithm, you can either write
your own 'sdec' (sound decompressor) component or simply have your program
decompress the sound itself. As before, if you can fit the decompressed sound in
memory, you can use any Sound Manager routine to play it. If you can't, you'll have to
decompress it in chunks and use SndPlayDoubleBuffer or a bufferCmd to play each
chunk. If you write your own 'sdec', of course, you can use any Sound Manager routine
that will play an arbitrarily compressed sound, but be sure to indicate that the sound
is compressed with your compressor so that the Sound Manager will know to call your
'sdec'.
Q How do I make a sound that will play on both Macintosh and PC computers? A This is actually easy, as long as you don't want to play compressed sounds. We recommend that you use WAVE files for both systems, since they'll play easily on the
Macintosh. (See the previous answer for some tips to help you play WAVE files on the
Macintosh.) Note, however, that there are many other formats that will work,
including AIFF and QuickTime.
Q How can I access the "Set Utilities Pattern" pattern? (This pattern, used as a background by certain system utilities like Find File, is normally set by holding down
the Option key in the Desktop Patterns control panel.)
A The Desktop Patterns control panel uses resources of type 'ppat' to store both desktop and utilities patterns. The 'ppat' resource is stored in the System file in your
System Folder; the desktop pattern has an ID of 16 and the utilities pattern has an ID
of 42. Since this isn't documented, it could be subject to change, so you should be
careful when using it.
Here's a snippet of code that shows how you can get the utilities pattern and then draw
with it:
PixPatHandle ppatHandle;
Rect destRect;
ppatHandle = (PixPatHandle) GetPixPat(42);
if (ppatHandle != NULL) {
SetRect(&destRect, 15, 125, 197, 164);
FrameRect(&destRect);
FillCRect(&destRect, ppatHandle);
DisposePixPat(ppatHandle);
}
QI discovered that if I hold down the Command key and click in the size box of a window, I can make the window bigger than the width I pass into GrowWindow. The size
box works as expected when the Command key isn't used. This seems to happen in every
application I've tried. I haven't been able to find any documentation discussing the
relationship between the Command key and the size box. I really need to limit the width
of my windows. Why is this happening and how can I work around it?
A Back in the old days when the Macintosh had a 9-inch screen (384 x 542 pixels), a lot of developers didn't follow Apple's guidelines for window sizes and hard-coded the
sizeRect given to GrowWindow based on this small size.
When the Macintosh II was introduced in 1987, Apple engineers felt it would be
frustrating for users not to be able to use the whole area of the new 13-inch monitors.
So Apple implemented the "Command-key grow" feature that you discovered, which
allowed users to get whatever size they wanted. However, this feature was not without
consequence to some applications, whose code couldn't handle larger-than-expected
window sizes. The "Command-key grow" feature is documented on page 209 of the old
Inside Macintosh Volume V, but wasn't documented in the newer Inside Macintosh
series.
It's trivial to deal with this feature if you really need to limit the window size: simply
check the size returned by GrowWindow, and if it's larger than you allow, reduce it to
your maximum allowed size before calling SizeWindow.
Q I've noticed that calling DeleteMenuItem mangles the menu data when handling menu items with strings that have between 251 and 255 characters. Does the Menu
Manager have a problem when handling menu items with strings that long?
A Yes, this is a problem, but it hasn't been documented in any Inside Macintosh books. The Menu Manager assumes that a menu item string isn't longer than 250
characters, so you shouldn't have menu items longer than that.
Q When I use ShowDragHilite with a picture filling my window, it highlights only the areas that are the same as the background of my window. Is there any way to fix this?
A Yes. ShowDragHilite isn't very savvy when overlaying image data other than the background color. The problem lies in QuickDraw's hilite mode. The operation of this
mode is based rather coarsely on the background color. We're working on a fix for this
problem, and eventually hilite mode will work significantly better in all cases,
including that of selecting cells in lists drawn by the standard LDEF. Until then, your
only alternative is to implement your own version of ShowDragHilite.
The question then becomes what color to use. Depending on your circumstances, you
may want to use black, white, or perhaps even inversion, although you should try to
avoid inversion against complex images if at all possible, since it can be ugly and
confusing. Should you decide hilite mode is insufficient, it's up to you to decide how
best to draw your highlight.
Q Sometimes my application's calls to the Drag Manager fail with a -600 (procNotFound) error. This isn't one of the errors listed for these calls. What's up?
A There are three known common causes of this error: • The use of high-level debuggers -- Since the Drag Manager interacts
heavily with the Process Manager, as does the typical high-level debugger,
conflicts inevitably develop. There's no workaround for this problem except to
ask your debugger vendor to improve the debugger's behavior when debugging